The permissions model that defines access control in existing virtualization environments is object centric. In particular, each object has privileges associated with it that are required to manipulate it. For a delegated user (e.g., a user given proper authorizations from, for example, a systems administrator) to acquire access to an object, the user needs to be given the proper set of privileges—ones that match what the object expects in order to take some action with respect to that object. These privileges are used by the virtualization environment to determine whether a specific user at a particular time has access authority to perform an action that the user desires to perform. In some virtualization systems and in other computing environments, such privileges (e.g., access rights and the like) are grouped into “roles,” and a user is allocated (e.g., designated, granted, assigned, directed etc.) roles based upon what activities he or she likely needs to perform within the infrastructure. A role tends to group together a large set of privileges, comprising many different activities a delegate user may need to perform over time. For example, a user acting in a system administrator role may need to perform different activities than a user acting in a software tester role.
For example, in a company with many employees that use virtual machines as testing environments for their software under development, it may be desirable to give access to each user to power on or off a particular virtual machine within the data center that has been configured for a particular test. Powering on a virtual machine might require one set of privileges, but a different task, such as moving the virtual machine to another host might require another set of privileges. It is not necessary in many such instances, or even desirable, that every user who has the ability to power on a virtual machine also be granted the ability to move his or her virtual machine to a different host in the infrastructure, as movement of virtual machines is often reserved to users involved in some aspect of the administration of the datacenter. Accordingly, on a frequent basis, especially in very large datacenters, system administrators need to define who has access to what within the virtualization infrastructure and exactly what those delegate users can do on various parts of the infrastructure. To properly grant access proactively, they therefore must predict ahead of time what roles various users will play with respect to the objects that are managed within the datacenter (sometimes referred to herein as managed inventory objects). Sometimes it is difficult to identify the full set of privileges necessary for a user to perform a particular task because many different, seemingly unrelated privileges may be necessary to perform that task. In addition, in some virtualization environments, permissions are propagated through complex inheritance structure rules, and thus it may be difficult for the administrator to understand exactly what permissions a particular user has been given at any time.
FIGS. 1A-1I are example screen displays of an existing user interface for administering permissions in a virtualization infrastructure according to a role-based paradigm. These displays have been generated from a VMware datacenter virtualization management product called vSphere™. FIG. 1A illustrates that a role 101 comprise privileges 102a-102d; a role 101 is associated with objects 122a-122d from an inventory objects folder 121 (e.g., managed objects in the datacenter inventory); a role 101 is associated with users 112a-112d, illustrated here as stored in an ActiveDirectory group 111; and inventory objects folder 121 is associated also with users 112a-112d in ActiveDirectory group 111. All three elements, one or more roles 101, objects folder 121, and the group of users 111 are used to define what a particular user is able to do with what object in the infrastructure. Each element also is associated with its own specialized user interface: role 101 is managed by roles interface 100; inventory object folder 121 is managed by user interface 120; and users (and groups of users) 111 are managed by interface 110.
In order to grant access to a user, under this system, the administrator either assigns an existing role to a user or defines a new role. FIG. 1B illustrates use of the user interface 100, here shown as dialog 131 in the vSphere client window 130, to define a new role called “VMs Only.” “VM” here refers to a virtual machine. As shown in FIG. 1B, the administrator selects which privileges, for example privilege “power on” 133 in the vApp category 132 for powering on a virtualized application. After selecting all of the desired privileges, the new role “VMs Only” 134 appears in the roles window of FIG. 1C as not yet in use (output text 135) since it has yet to be assigned to a particular user.
The administrator now needs to determine to which object to associate the role using user interface 120 (FIG. 1A). FIG. 1D illustrates that the administrator has selected an object in the datacenter “Bobby's VMs” (a folder) to which the new role will be assigned. The current set of roles already allocated to the object “Bobby's VMs” are shown under the permissions tab 142. To add the newly developed role “VMs Only,” the administrator brings up the assign permissions dialog through add permissions menu 143 or other user interface (UI) control. The assign permissions dialog 150, as shown in FIG. 1E, allows the administrator to select the newly defined role 153 from a roles menu 152. The administrator also can indicate using UI control 154 whether objects further down in the object definition hierarchy will inherit this role as well. For example, all virtual machines (VMs) in Bobby's folder may inherit this role assignment because the UI control 154 has been selected. When the administrator indicates that the administrator is done (by, for example, pressing the “OK” button 155), the administrator can then select the users and/or groups who will be assigned the new role.
FIG. 1F illustrates an example process for selection of a user for role assignment. In a separate user selection dialog 160 (e.g., UI 110 in FIG. 1A), the administrator chooses that Bobby (icon 161) will have the new role assigned to him. Once this entire cycle is complete (define new role, assign to an object, assign to a user/group), the administrator can see in field 171 of the assign permissions dialog 150, as shown in FIG. 1G, that the new role “VMs Only” has been assigned to Bobby and an indication 172 of what permissions are available to Bobby in that role. The administrator can check, using the inventory UI illustrated in FIG. 1H, that the new permissions 182 have been assigned to Bobby 181 with respect to the object Bobby's VMs. As shown in FIG. 1I, when the administrator now looks at the roles defined in the system, the administrator can see the new role 134 and where and to whom it has been assigned (description 191).
Unfortunately, without asking Bobby to actually try out his newly assigned permissions, the administrator has little idea whether Bobby's new role will work as intended. If Bobby tries to add a new virtual machine and it doesn't operate as expected (e.g., he receives an error message), then the administrator must cycle through some number of the dialogs again to add more privileges and/or assign them to different inventory objects, round and round, until Bobby is successful. Moreover, because of the intricate structure of the propagation and inherency of roles across the infrastructure, it may be difficult to determine which roles are in actuality accessible to Bobby.